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Section  1 .  Introduction 


Air  Force  equipments,  subsystems,  and  systems  are  becoming  even  more  complex  in  terms  of  the 
number,  type,  and  operating  parameters  of  functions  which  must  be  performed  with  reliability  and 
effectiveness.  Shared  frequency  bands  and  antennas  and  limited  real  estate  create  a  matrix  leading  to 
electromagnetic  interference  and  component  bum-out.  Numbers  of  components  are  increasing  at  a  high 
rate,  and  even  a  minor  or  temporary  failure  of  any  one  component  can  result  in  degraded  operation  of  the 
system,  aborted  missions,  and  unacceptable  safety  hazards  to  personnel  and  ordinance. 

At  the  same  time  that  the  design  and  development  requirements  are  becoming  more  stringent  and  system- 
and  function-unique,  the  time  and  funding  available  for  these  activities  are  being  minimized.  It  is  no 
longer  possible  to  employ  the  “cut-and-try”  method.  The  goal  in  product  design  is  “first  pass”  acceptance 
to  achieve  affordable  system  acquisition  costs. 

Furthermore,  due  to  the  complexity  of  the  system  and  the  operational  requirements,  it  is  no  longer 
possible  to  test  every  possible  combination  of  environmental  factors  and  operational  scenarios  to  ensure 
combat  readiness.  The  components  and  equipments  must  work  satisfactorily  every  time,  even  when  the 
system  first  enters  a  severe  environment. 

Modeling  and  simulation  during  all  phases  of  the  acquisition  cycle,  as  shown  in  Figure  1,  especially 
during  early  concept  and  design  studies,  is  perhaps  the  only  viable  avenue  available  within  the  above 
acquisition  constraints.  Alternative  product  and  system  concepts  can  be  postulated  and  investigated 
without  costly  experimentation.  A  broader  range  of  possibilities  can  be  studied  on  the  computer  than  at 
an  experimental  facility.  A  larger  set  of  environmental  factors  can  be  applied  under  very  controlled 
circumstances  on  the  computer  than  can  be  done  experimentally.  Sensitivity  analyses  of  operational 
performance,  failure  predictions,  time  to  repair,  etc.  as  a  function  of  incremental  changes  in  the 
operational  environment  and  product  design  can  be  obtained  which  provide  information  for  training,  for 
product  improvement,  and  for  the  determination  of  safety  margins  and  reliability  factors. 

Test  resources,  schedules,  processes,  and  testability  issues  (e.g.,  integrated  diagnostics  and  built-in-test) 
can  also  be  add-essed  through  modeling  and  simulation.  This  can  reduce  the  costs  associated  with  DT&E 
and  OTi&E,  and  periodic  test  and  maintenance. 

Conceptually,  then,  computerized  modeling  and  simulation  provide  a  solution  to  today’s  complex 
technological  explosion  and  acquisition  environment  of  reduced  available  resources.  As  a  result  the  Air 
Force,  DoD  in  general  [A.5,  A.7,  A.9],  and  the  civilian  sector,  are  placing  increasing  emphasis  on  the  use 
of  modeling  and  simulation  (M&S)  in  the  design,  acquisition,  and  performance  evaluation  of  their  various 
products.  “Product,”  and  alternatively  “object,”  can  be  defined  as  a  device,  a  board,  a  module,  a 
subsystem  (e.g.,  conmiunications),  or  a  system  (e.g.,  F16).  The  concept  of  a  product  model  includes  not 
only  the  physical  characteristics  of  the  product,  but  also  the  processes  associated  with  its  manufacture  and 
operation.  For  completeness  there  must  also  be  included  the  environment  in  which  it  will  operate  and  a 
consideration  of  its  interaction  with  and  relationship  to  other  products. 

In  response  to  these  circumstances  the  topics  of  M&S  frameworks  and  product  databases  are  seeing 
greater  emphasis.  A  framework  can  be  thought  of  as  an  environment  in  which  a  particular  simulation  is 
executed  in  concert  with  a  number  of  other  simulations.  The  fimnework  establishes  a  set  of  specifications 
for  the  execution  of  the  simulation,  specifications  for  input/output  data  management,  and  a  run-time 
infi:astructure  to  coordinate  and  facilitate  the  execution  of  the  individual  simulations  and  management  of 
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the  data.  The  framework  functions  invisibly  behind  the  scenes  to  allow  a  particular  application  to  run 
while  others  are  also  executing.  The  activities  are  coordinated.  Data  are  managed,  and  the  user 
concentrates  on  his  or  her  work. 
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Figure  1.  Modeling  &  Simulation  in  the  Acquisition  Cycle 


The  DoD  and  the  Services  are  developing  M&S  frameworks  to  accomplish  a  broad  variety  of 
collaborated  simulations.  DARPA  is  in  the  final  year  of  a  five-year  effort  to  develop  a  Simulation  Based 
Design  (SBD)  environment.  Its  objective  is  to  develop  and  demonstrate  the  concept  of  Virtual 
Prototyping  in  order  to  exploit  the  cost  and  time  saving  benefits  of  simulation  technology  in  the  design  of 
complex  mechanical  systems.  An  overview  can  be  found  at  http://www.arpa.mil/asto/SBD/sbd.html. 

The  Defense  Modeling  and  Simulation  Office  (DMSO)  is  developing  a  High-Level  Architecture  (HLA) 
scheme  to  establish  a  common  technical  framework  to  facilitate  the  interoperability  of  all  types  of  models 
and  simulations  among  themselves  and  with  C4I  systems,  as  well  as  to  facilitate  the  reuse  of  M&S 
components.  The  overall  DMSO  program  encompasses  M&S  specifications,  object  model  definitions, 
and  a  run-time  infi-astructure  (RTl)  to  coordinate  the  execution  of  the  multiple  simulations.  Further 
details  can  be  found  on  the  Web  at  http://hla.dmso.mil/. 

The  framework  and  the  modeling  and  simulation  environment  address  one  need  for  computer-aided 
distributed,  collaborative  design  and  analysis.  A  second  equally  important  and  pervasive  requirement  is 
intelligent  management  of  the  data  associated  with  the  product  being  designed  and  developed.  Figure  2 
shows  that  there  are  many  ways  to  categorize  the  modeling  and  simulation  opportunities  throughout  the 
life  cycle  of  the  product.  It  is  expensive  to  collect  the  quantity  and  quality  of  data  required  within  any  one 
compartment  It  is  equally  expensive  and  necessary  to  ensure  continuity  and  consistency  horizontally 
among  neighboring  compartments  and  vertically  among  levels  of  sophistication. 
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Figure  2.  Life-Cycle  Modeling  and  Simulation 


There  is  a  hierarchy  which  begins  with  the  fine  details  of  a  circuit  and  extends  “upward”  to  a  less  detailed 
but  more  inclusive  system  description  and  analysis.  Numerous  intermediate  levels  can  also  be  defined 
depending  on  the  nature  of  the  object  under  analysis.  At  each  level,  as  noted  previously,  the  analysis 
tools  of  the  many  engineering  disciplines  are  interactively  exercised. 

Each  hierarchical  level  will  be  evaluated  at  the  many  steps  which  comprise  the  system  cycle.  At  the 
concept  stage  there  is  very  little  detail  available,  and  analysis  provides  only  very  general  conclusions 
regarding  product  performance.  Succeeding  stages  will  involve  more  detail  regarding  the  product  design 
specifications,  and  therefore  more  sophisticated  analysis  tools  will  provide  a  more  accurate  and  complete 
assessment  of  product  performance.  After  it  is  initially  fielded  or  integrated  into  a  large  system,  the 
product  and/or  the  system  will  undergo  modifications.  Models  and  data  that  were  developed  and  obtained 
during  the  initial  acquisition  cycle  will  increase  the  efficiency  of  the  enhancement  design  process. 

The  framework  that  has  been  under  development  will  facilitate  the  transfer  of  data  and  maximize  its  reuse 
during  the  various  stages  of  the  design  and  acquisition  cycle.  It  is  generic  in  that  it  is  applicable  to  all 
levels  of  product,  from  devices  and  boards  to  equipments  and  systems.  What  is  of  extreme  importance  is 
that  a  tremendous  amount  of  very  detailed  and  very  accurate  high  resolution  performance  data  are 
generated  and  stored  using  the  built-in  functions  and  utilities  of  the  framework.  These  data  can,  and  more 
importantly  should,  contribute  to  the  performance  analysis  of  the  product  and/or  system  when  it  is  being 
evaluated  in  even  higher  levels  of  analysis  (e.g.,  theater,  order  of  battle).  As  an  example,  Figure  3 
demonstrates  how  the  acquisition  cycle  engineering  analysis  data  could  be  interfaced  into  the  Joint 
Modeling  and  Simulation  System  (JMASS).  The  high  resolution  data  could  be  collected  in  the  form  of 


look-up  tables  which  are  accessed  by  the  high-level  simulations  to,  for  example,  determine  air/ground 
communication  performance  in  the  presence  of  a  hostile  stand-off  jammer.  An  alternative  is  to  reduce  the 
analysis  data  by  casting  it  into  the  form  of  equations  which  are  specific  to  a  system  in  a  high-level 
analysis.  The  specific  data  would  then  be  calculated  on-the-fly  rather  than  accessed  through  a  look-up 
table.  In  either  case  the  best  available  data  would  be  utilized,  thereby  reducing  the  probability  of 
uncertainty  associated  with  a  command-level  decision. 


JSIMS/JWARS 


Figure  3.  Joint  Modeling  and  Simulation  System  Interface  Concept 


This  illustrates  another  advantage  of  the  proposed  product.  Once  the  model  has  been  exercised  in  the 
theater-level  simulation,  data  may  be  fed  back  to  the  acquisition  and  development  teams  in  the  form  of 
revised  specifications.  It  may  happen  that  the  antenna  performance  was  not  as  expected,  or  that  the 
original  specification  may  not  have  provided  adequate  coverage.  The  feedback  can  then  flow  down  the 
pyramid  to  the  appropriate  level,  engineering  domain(s),  and  resolution  of  analysis.  In  this  way  this  new 
information  can  result  in  a  product  and  performance  that  are  more  responsive  to  the  operational 
requirements  of  the  system  and  its  components. 
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Section!.  Deficiencies 


Today’s  modeling  and  simulation  environment  can  be  characterized  as  disjointed  in  the  sense  that  each 
engineering  and  support  discipline  (e.g.,  thermal  analysis,  software  reliability)  operates  in  its  own 
microcosm,  even  though  many  analysis  tools  are  applied  to  the  same  product  under  development. 

Generally,  there  is  no  efficient  mechanism  for  the  results  of  an  analysis  in  one  engineering  discipline  to  be 
used  in  the  analysis  process  of  another.  The  translations  that  are  necessary  to  prepare  the  output  data  of 
one  analysis  for  use  as  a  driving  function  for  a  second  analysis  are  performed  by  some  locally  generated, 
poorly  documented  utility  program.  For  example,  an  electromagnetic  analysis  can  be  performed  to 
determine  how  the  presence  of  an  airborne  platform  will  affect  the  performance  of  a  phased  array  antenna 
and  to  locate  the  anteima  to  maximize  some  performance  parameter  of  the  antenna.  This  will  in  turn 
affect  the  flight  dynamics  of  the  aircraft,  but  the  data  needed  by  an  aeronautical  analyst  to  ascertain  the 
affect  on  platform  performance  is  not  readily  available  from  the  results  of  the  electromagnetic  analysis. 

Another  loss  of  opportunity  is  in  the  area  of  system  and  environmental  database  use  and  reuse.  All 
computer  models  of  physical  objects  begin  with  the  geometrical  and  electrical  description  of  the  system. 
Through  some  manual,  or  in  rare  cases  automated,  process  this  physical  geometry  is  translated  into  a 
computer  model  which  is  understandable  to  only  one,  or  at  most  a  small  number  of,  computer-aided 
simulation  codes.  This  leads  to  repetitive  and  redundant  modeling,  incomplete  models,  inaccurate 
models,  models  not  being  available,  or  models  not  at  the  appropriate  level  of  detail  for  the  simulation 
currently  being  performed. 

Finally,  it  is  very  difficult  to  ensure  that  all  members  of  the  development  team  are  working  with  the  same 
edition  of  the  design  data.  This  is  especially  true  when  there  exist  several  subcontractors  interfacing  with 
an  integrating  contractor,  who  is  under  contract  to  a  system  program  office  (SPO).  In  the  early  phases  of 
the  design  process  the  data  are  in  a  very  fluid  state,  and  it  is  quite  possible  that  some  engineering 
disciplines  are  developing  a  model  and  performing  simulations  using  geometrical  and/or  electrical  data 
that  are  one  or  more  editions  out  of  date. 

To  eliminate  these  drawbacks  in  the  modeling  and  simulation  technology  it  is  necessary  for  the  product 
development  team  to  carry  out  its  effort  within  a  defined  workspace  which  includes  the  appropriate 
toolsets  and  a  self-consistent  set  of  product  data  on  which  the  tools  within  a  set  operate.  TTie  environment 
must  accommodate  numerous,  diverse  engineering,  support,  and  management  disciplines,  including,  but 
not  limited  to,  circuit  analysis,  reliability,  testability,  maintainability,  electromagnetic  hardness,  signal 
processing,  and  computer-aided  design.  It  will  also  provide  for  the  configuration  control  functions  of  all 
data  associated  with  tiie  product  under  development. 
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Section  3.  Objective  and  Scope  of  the  Current  Effort 


The  overall  objective  of  this  program  is  the  design,  development,  and  demonstration  of  an  “open 
architecture”  computer-based  environment  which  will  be  applicable  to  products  at  all  levels  of  complexity 
(i.e.,  from  device  to  system)  and  at  all  phases  of  the  acquisition  cycle,  including  subsequent  modification 
of  the  system  in  which  the  product  is  operating.  This  environment  will  be  capable  of  supporting  the 
computer-aided  design  and  analysis  tools  for  all  engineering  disciplines,  management  function,  and 
configuration  control  of  all  data  associated  with  the  development  of  the  product.  This  is  depicted 
graphically  in  Figure  4. 

The  focus  of  this  in-house  effort  has  been: 

>  Design  and  develop  a  robust,  open-architecture  environment 

>  Populate  the  environment  with  the  available  tools  which  can  characterize  the  reliability, 
maintainability,  and  testability  of  the  product,  as  well  as  those  tools  which  will  be  needed  for  the 
demonstrations;  and, 

>  Demonstrate  the  utility  of  the  environment  via  the  integration  of  sensors  on  an  airborne 
surveillance  platform. 


Figure  4.  Integrated  Computational  Environment  Concept 


A  prototype  of  the  Integrated  Computational  Environment  (ICE)  suitable  for  dissemination  and  use  by  the 
DoD  and  its  contractors,  as  well  as  by  the  civilian  sector  for  the  design  and  development  of  consumer 
electronics  products,  will  exist  as  a  result  of  this  effort.  Included  will  be  complete  documentation  for  its 
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maintenance  and  enhancement,  as  well  as  training  courses  for  the  use,  maintenance,  and  enhancement  of 
the  ICE.  The  initial  population  of  tools  will  include  those  inserted  for  reliability,  maintainability, 
testability,  system-  and  circuit-level  electromagnetic  effects,  and  those  tools  used  for  the  demonstrations. 
The  architecture  and  structure  of  the  ICE  will  be  robust  such  that  the  tools  of  any  engineering  and  physics 
disciplines  can  be  inserted  with  minimum  modification  to  the  coding  and  execution  of  the  tool. 

The  following  is  a  list  of  features  of  Integrated  Computational  Environment,  for  which  the  design  and 
implementation  must  take  account: 

>  Modular  design  allowing  user  flexibility  and  customizability 

>  Standard  suites  of  simulation  tools  for  numerous  engineering  disciplines 

>  Software  utilities  to  “plug  and  play”  user  design  and  analysis  codes 

>  Graphical  User  Interface  (GUI)  with  an  extensive  menuing  system 

>  Context-sensitive  HELP  system  with  hypertext  links 

>  Use  of  standard  protocols  for  user  choice  of  geometry  drawing  and  database  packages 

>  Ability  to  spawn  processes  on  remote  computers 

>  Configuration  control  utilities  for  design  data  management 

>  Main  control  panel  allows  user  total  control  over  design  process 

>  Expert  System  module  available  to  support  analysis  model  development 

>  Full-Feature  data  visualization  package  available 

>  Telephone  and  on-site  support 
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Section  4.  Overview  of  Accomplishments 


This  section  contains  a  summary  of  each  of  the  efforts  which  have  been  a  part  of  the  overall  ICE  program. 
Some  details  of  each  of  the  efforts  are  contained  in  succeeding  sections  of  this  report.  Complete 
information  for  each  effort  is  contained  in  the  supporting  documentation  for  that  effort,  which  is  listed  in 
the  bibliography  at  the  end  of  this  report. 

Figure  5  shows  the  flow  of  the  efforts  associated  with  the  development  of  the  ICE.  The  bottom  element  is 
the  in-house  program  which  has  been  described  in  the  previous  sections  of  this  report.  The  current  effort 
ends  at  the  beginning  of  FY99.  The  “Enhancement”  is  an  unfunded,  “unprogrammed”  in-house  program 
at  the  present  time. 

The  top  line  represents  the  last  phase  of  the  development  of  the  Microwave  and  Millimeter-Wave 
Advanced  Computational  Environment  (MMACE),  which  was  funded  by  the  Naval  Research  Laboratory. 
The  Information  Directorate  of  the  Air  Force  Research  Laboratory  (formerly  known  as  Rome  Laboratory) 
was  the  technical  manager  of  the  MMACE  development  effort.  The  MMACE  program  developed  and 
fielded  a  UNIX-based  computational  environment  for  the  design  and  analysis  of  high-power  microwave 
tubes.  The  elements  of  this  environment  were  integrated  into  and  distributed  as  the  Research  and 
Engineering  Framework  (REF),  which  is  depicted  in  figure  6.  The  MMACE  program  also  integrated 
numerous  tube  design  tools  with  the  REF  and  each  other.  Structural,  thermal,  electromagnetic,  and 
particle-in-cell  design  and  analysis  tools  now  seamlessly  exchange  data  and  interactively  design  the  tube. 
Version  3  of  MMACE  has  been  fielded  to  the  high  power  microwave  tube  community  and  is  being  used 
at  the  Naval  Research  Laboratory  for  its  research  and  development  in  the  technology  underlying  the 
operation  and  application  of  these  tubes  for  surveillance  and  communication. 
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Figure  5.  Integrated  Computational  Environment  Development  Roadmap 
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Figure  6.  Elements  of  Research  &  Engineering  Framework 


The  REF  contains  application  program  interfaces,  documented  specifications,  and  software  utilities  to  aid 
the  integration  of  design  and  analysis  codes  with  the  REF.  In  addition,  it  provides  the  data  management, 
networking,  visualization,  and  “Master”  geometry  needed  to  drive  analysis  codes.  The  REF  also  provides 
the  utilities  needed  to  construct  graphical  user  interfaces  including  the  top-level  control  panel.  The  REF 
can  be  compared  to  a  computer  operating  system;  generic,  powerful,  and  providing  much  functionality, 
but  of  little  interest  to  the  end  user  who  requires  software  that  is  written  to  operate  on  top  of  it. 

The  REF  was  designed  and  developed  to  be  generic  with  respect  to  the  engineering  disciplines  that  would 
malcR  use  of  it.  To  that  end  an  interface  called  the  data  dictionary  support  software  was  included.  It 
provides  the  link  between  the  generic  REF  and  the  discipline-specific  data  model  which  applies  to  the 
design  and  analysis  tools  associated  with  a  specific  engineering  discipline. 

During  FY94  and  FY95  the  Air  Force  funded  the  design  and  development  of  a  data  dictionary  for 
computational  electromagnetics.  Recognizing  that  many  such  disciplines  interact  with  each  other  and 
share  much  of  the  structural  and  analysis  data,  a  separate  effort  was  initiated  (FY94-FY95)  to  investigate 
the  issues  associated  with  a  global  database  for  use  in  the  design  and  analysis  process  of  an  object.  The 
intent  is  to  have  the  global  database  mature  with  the  object  it  describes  and  be  available  to  all  members  of 
the  development  team,  as  well  as  be  available  to  all  team  members  for  all  future  enhancements  to  the 
object.  A  more  detailed  description  of  this  work  is  given  in  Section  6  of  this  report. 

As  seen  in  Figure  5,  all  arrows  lead  to  a  “Demonstration.”  The  objective  of  this  contractual  effort  is  to 
interface  and  integrate  the  various  products,  concepts,  and  processes  that  have  been  developed  under  the 


9 


broad  umbrella  of  the  ICE  program  and  enhance  and  modify  them  as  necessary  for  operation  within  the 
Windows95/NT  environment  (rather  than  UNIX).  The  demonstration  focuses  on  the  placement  of 
antennas  on  board  a  selected  aircraft  to  characterize  and  maximize  their  functional  performance  and 
minimize  interference  from  and  to  other  antenna-driven  equipments  and  subsystems.  This  effort  will 
identify  areas  requiring  further  work  to  be  done  under  a  more  substantially  funded  full-scale  development 
program,  identify  the  processes  and  develop  the  software  to  facilitate  the  interface  of  computer-aided 
design  and  analysis  tools  to  the  REF,  validate  the  CEM  data  dictionary  and  provide  a  template  for  the 
development  of  data  dictionaries  for  other  engineering  disciplines,  and  aid  in  the  design  and  development 
of  one  or  more  training  courses  for  the  use  of  the  ICE  and  REF  in  product  design  and  acquisition.  A  more 
detailed  description  of  this  work  is  given  in  Section  5  of  this  report. 

Three  SBIRs  have  been  associated  with  the  development  of  the  ICE.  They  each  have  addressed  a  generic 
technology  associated  with  product  design  and  acquisition,  and  each  has  used  CEM  as  a  focus  technology 
area  to  demonstrate  the  interfaces,  tools,  and  processes  associated  with  implementing  simulation-based 
design  and  acquisition.  The  first  area  is  the  use  of  the  world-wide  web  for  remotely  managing  data  and 
performing  design  and  analysis  within  the  paradigm  of  distributed  processing.  Ultra  Corp.  initially 
parallelized  the  GEMACS  (General  Electromagnetic  Model  for  the  Analysis  of  Complex  Systems)  code 
in  order  for  it  to  perform  its  analysis  process  in  a  shorter  turn-around  time,  or  to  more  completely 
characterize  the  electromagnetic  posture  of  a  system  within  the  time  it  took  to  perform  a  more  limited 
characterization  using  a  traditional  sequential  processor.  As  part  of  its  commercialization  effort  the 
contractor  developed  web-based  forms  and  procedures  for  submitting  the  input  data,  remotely  executing 
GEMACS,  and  downloading  analysis  output  upon  completion  of  the  execution.  One  element  within  the 
“Demonstration”  contract  is  to  demonstrate  this  analysis  process  within  the  confines  of  the  REF  Control 
Panel.  A  more  detailed  description  of  this  work  is  given  in  Section  7  of  this  report. 

A  second  area  critical  to  product  design  and  analysis  is  visualization.  This  includes  seeing  the 
geometrical  representation  of  the  structure,  the  definition  and  modification  of  the  analysis  model,  and  the 
presentation  and  aimotation  of  the  analysis  data.  The  objective  of  this  effort  is  to  develop  a  flexible 
capability  to  capture  a  digitized  representation  (e.g.,  IGES,  DXF)  of  the  object  and  aid  the  analyst  in 
developing  an  appropriate  analysis  model.  The  visualization  package  will  allow  for  many  of  operations 
that  can  be  foimd  in  commercially  available  photo  and  presentation  graphics  packages  (e.g.,  PowerPoint, 
Photoshop),  such  as  zoom,  hide,  align,  and  group.  Analysis  tool-specific  translators  will  generate  an 
input  data  stream  from  the  model.  A  third  function  of  the  visualization  package  will  collect,  process,  and 
display  the  data  in  a  format  and  annotation  that  is  most  appropriate  for  the  data  being  displayed,  the 
purpose  of  the  display,  and  the  intended  audience  for  the  display.  A  more  detailed  description  of  this  work 
is  given  in  Section  8  of  this  report. 

The  third  area  of  technology  is  investigating  the  use  of  Artificial  Intelligence  (AI)  technology  to  aid  in  the 
development  of  analysis  models.  The  analysis  tools  are  becoming  more  and  more  capable  of  treating  very 
high  resolution  models  which  are  composed  of  hundreds  of  thousands  of  modeling  elements.  Curved 
surfaces,  the  interface  of  two  or  more  elements  (e.g.,  wing  coimection  to  the  fuselage  of  an  aircraft),  and 
material  properties  as  a  function  of  surface  location  and  layered  can  now  be  modeled  with  higher-order 
expansion  fimctions.  Indeed  they  must  be  if  the  designer  or  system  integrator  needs  to  get  a  true  measure 
of  product  or  system  performance.  Model  development  packages  must  incorporate  AI  technology  to 
maVft  the  process  manageable  for  the  analyst,  both  when  the  model  is  first  being  developed  (perhaps  from 
the  computer-generated  specification  which  guides  the  computerized  machining  tools)  and  for 
modification  of  an  existing  model  to  reflect  a  structural  change  in  the  physical  object  or  to  increase  or 
decrease  the  resolution  of  the  model  in  certain  regions  caused  by  a  change  in  the  requirements  or 
objective  of  the  analysis.  The  particular  effort  shown  in  Figure  5  is  an  SBIR  contract  to  develop  an 
intelligent  preprocessor  for  use  in  CEM  analysis.  GEMACS  is  again  one  of  the  focus  codes,  but  several 
other  CEM  codes  (e.g.,  CARLOS,  NEC,  BSC)  are  driving  the  design  and  development  of  the 
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preprocessing  tool.  This  is  to  ensure  that  the  tool  is  generic  with  respect  to  the  CEM  formulations  and 
instantiations  of  the  formulations,  and  to  aid  in  the  interface  of  several  formulations,  each  of  which  is 
more  or  less  appropriate  for  the  observables  to  be  calculated,  regions  of  interest  in  which  the  performance 
is  to  be  characterized,  and  the  degree  of  fidelity  and  resolution  to  which  the  material  properties  of  the 
physical  structure  are  to  be  modeled.  Although  the  original  release  of  the  preprocessor  will  focus  on 
electromagnetics,  it  is  planned  that  future  releases  will  fold  in  other  engineering  disciplines  (e.g.,  thermal, 
structural,  fluid  dynamics).  It  should  be  noted  that  the  data  dictionary  schema  is  being  used  as  one  of  the 
foundational  elements  underpinning  the  design  and  development  of  the  preprocessor  and  its  local  data 
storage  scheme.  A  more  detailed  description  of  this  work  is  given  in  Section  9  of  this  report. 

The  in-house  program  has  brought  these  various  elements  together,  analogous  to  the  role  of  an  integrating 
contractor.  One  of  the  functions  being  performed  has  been  the  coordination  among  the  numerous 
contracts  and  contractors  to  develop  tools  and  processes  which  complement  each  other  and  work  together 
to  achieve  the  vision.  This  is  accomplished  by  conducting  common  review  meetings  and  maintaining  a 
fairly  free  flow  of  information  among  the  participants.  Products  in  progress  have  been  installed  on  AFRL 
computers,  or  access  to  products  have  been  provided  remotely.  Ad  hoc  testing  and  demonstrations  have 
shown  where  there  are  inconsistencies  or  shortcomings,  which  need  to  be  addressed  either  under  the 
current  series,  or  more  likely  under  follow-on  efforts  (shown  as  “Full  Scale  Development”  in  Figure  5). 
Funding  for  this  work  must  be  provided  in  order  that  the  Air  Force  and  DoD  will  have  a  computer-aided 
acquisition  capability  available.  See  Section  10,  “Summary  and  Recommendations,”  for  more  detailed 
information. 
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Sections.  Research  &  Engineering  Framework  Control  Panel 


As  mentioned  in  Section  4,  the  REF  acts  as  the  interface  in  a  number  of  ways: 

>  Between  the  user  and  the  application  codes  and  data 
^  Between  the  application  codes  and  the  computer 

^  Among  the  various  application  codes  with  each  other  and  with  the  product  database 

Figure  6  has  been  modified  to  show  the  current  elements  of  the  PC-based  REF,  which  has  been  developed 
under  the  Demonstration  effort.  See  Figure  7.  A  major  achievement  has  been  the  port  from  the  UNDC 
platform  to  the  Windows95/NT  platform. 
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Figure  7.  Elements  of  the  PC-Based  Research  &  Engineering  Framework 


The  Graphical  User  Interface,  called  the  Control  Panel  (CP),  has  been  a  main  focus  of  attention  of  the 
Demonstration  effort.  Figure  8  shows  the  present  state  of  the  CP.  As  can  be  seen  in  the  figure,  the  look 
and  feel  have  been  designed  to  look  and  act  very  much  like  the  standard  Windows95/NT  program 
screens.  There  is  a  menu  bar  which  provides  access  to  the  functions  and  operations  available  within  REF. 
Figure  9  shows  these  functions.  Of  particular  interest  is  the  menu  item  called  “Code  Pool.”  This  is  a  list 
of  the  analysis  tools  and  utilities  which  have  been  interfaced  with  the  REF.  It  is  a  relatively  simple  matter 
to  add  codes  to  the  pool  and  provide  the  parameters  via  the  properties  box.  Figure  10  shows  a  screen  shot 
of  the  CP  after  the  user  has  clicked  on  the  Code  Pool  menu  item.  Double-Clicking  or  right-clicking  on 
one  of  the  executable  icon  brings  up  the  properties  box  in  which  the  user  sets  such  parameters  as  location 
of  the  executable  of  the  code  and  location  of  input  and  output  data  files,  if  appropriate. 
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Figure  8.  PC-Based  REF  Control  Panel 
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Figure  9.  Control  Panel  Functions  and  Operations 
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Figure  10.  Code  Pool  and  Properties  Box 


The  CP  allows  the  user  to  define  in  the  Canvas  area  an  analysis  process  using  the  various  analysis  codes 
that  have  been  interfaced  with  the  REF  and  whose  names  appear  on  the  Code  Pool  menu  item.  Figure  1 1 
shows  a  process  that  could  be  used  to  analyze  the  performance  of  one  or  more  antennas  located  on  an 
aircraft.  Users  define  not  only  what  analysis  codes  are  to  be  used,  but  they  define  as  well  the  sequence  in 
which  those  codes  are  executed.  Decision  points  and  looping  can  also  be  accomplished  in  the  definition 
of  the  analysis  process.  The  process  shown  is  notable  for  two  reasons.  First,  it  shows  that  an  analysis 
may  be  executed  remotely.  The  bottom  icon  in  the  left-hand  column  spawns  a  process  called  “Simulation 
on  Demand”  which  is  provided  by  the  Ultra  Corporation  (see  Section  7).  Notification  of  completion  is 
provided  via  e-mail  to  the  owner  of  the  workspace.  The  data  are  returned  to  the  local  machine  via  ftp. 
They  can  then  be  processed  locally.  As  part  of  this  processing  data  necessary  to  initiate  a  circuit  analysis 
(e.g.,  on  the  transmit/receive  module  connected  to  the  antenna  terminals)  can  be  extracted  or  developed  to 
provide  a  driving  function  or  terminal  load  for  the  circuit  simulation.  Thus,  the  example  process  shown  in 
the  figure  demonstrates  that  two  of  the  major  requirements  for  the  Integrated  Computational  Environment 
have  been  achieved. 

The  CP  Tool  Bar,  shown  in  Figure  8  and  in  greater  detail  in  Figure  12,  contains  the  icons  for  many  of  the 
functions  and  operations  that  are  available  via  the  menu.  Notice  that  tiie  icons  are  consistent  with  those 
that  are  found  in  any  typical  Windows95/NT  application.  This  minimizes  the  learning  curve  for  the  user 
as  well  as  the  long-term  maintenance  for  the  Control  Panel  if  the  operating  system  or  conventions  should 
change. 

The  Status  Area,  shown  in  Figure  8  and  in  greater  detail  in  Figure  13,  contains  information  about  the 
operation  of  the  REF,  the  CP,  and  the  code  being  executed.  Again,  the  format  and  data  are  very  similar  to 
those  found  in  most  Windows95/NT  applications,  and  for  the  same  reasons  as  noted  for  the  Tool  Bar. 
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The  documents  cited  in  section  B  of  the  References  Section  contain  more  detailed  information  about  the 
work  performed  in  this  technology  area. 


Figure  12.  REF  Control  Panel  Tool  Bar 


Figure  13.  REF  Control  Panel  Status  Area 
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Section  6.  Data  Dictionary  and  Product  Database 


As  mentioned  in  Section  4,  it  is  the  Data  Dictionary  which  is  the  link  between  the  generic  REF  and  a 
specific  engineering  design  and  analysis  domain.  A  data  dictionary  is  a  catalog  that  thoroughly  details  all 
the  entities,  their  attributes,  and  relationships.  It  is  “data  about  the  data.”  A  relational  database  system 
needs  to  maintain  data  about  the  relations  among  the  data.  Included  in  the  types  of  information  the  data 
dictionary  stores  on  the  product  or  object  are: 

>  Names  of  the  relations 

>  Names  of  the  attributes  within  each  relation 

>  Domains  of  attributes 

>  Names  of  views  defined  on  the  database,  and  die  definition  of  those  views 

>  Integrity  constraints  for  each  relation  (for  example,  allowable  ranges  for  attributes  in  the 
relations) 

As  part  of  this  program  a  data  dictionary  for  CEM  was  begun  and  continually  refined,  both  in  terms  of  its 
structure  and  its  growth  in  the  number  of  CEM  modeling  elements  that  have  been  incorporated  within  the 
schema.  The  objective  has  been  to  develop  a  dictionary  that  is  applicable  to  all  CEM  formulations  (e.g., 
method  of  moments  (MoM) ,  uniform  theory  of  diffiaction  (UTD),  finite  element  methods  [FEM]), 
encompasses  both  frequency  domain  analysis  and  time  domain  analysis,  and  is  code-independent.  The 
dictionary  must  treat  three-dimensional  objects,  taking  into  account  layered  materials  and  accounting  for 
differing  material  properties  in  each  layer.  Furthermore,  it  must  reference  foimdational  elements  for 
simplicity,  ease  of  extension,  and  minimal  redundancy.  For  example,  the  simplified  schema  shown  in 
Figure  14  identifies  a  region  as  planar.  This  is  a  class  of  CEM  modeling  elements  which  has  a  flat  face 
with  one  or  more  layers  of  arbitrary  thickness  in  the  third  dimension.  This  includes  the  patch  used  in 
MoM  and  the  brick  in  FEM,  the  flat  plate  used  in  GTD,  and  the  facets  used  to  model  a  geometry  to  be 
analyzed  by  the  shooting-and-bouncing  ray  (SBR)  technique. 

The  hierarchical  nature  of  the  schema  can  easily  be  seen  in  the  figure.  This  facilitates  data  re-use.  There 
is  the  MASTER  which  points  to  two  major  groups  of  data,  each  of  which  is  found  in  any  typical 
computational  electromagnetics  code.  A  code  will  have  an  input  file  comprised  of  execution  commands 
which  identify  frequencies,  global  parameters,  and  output  quantities  to  be  calculated.  The  second  part  of 
the  input  defines  the  computational  electromagnetics  model  of  the  structure  to  be  analyzed.  Within  the 
schema  as  drawn  in  Figure  14  the  execution  elements  are  grouped  on  the  left-hand  side  (“Execution”). 
Sources,  loads,  and  output  specifications  are  found  here.  The  right-hand  side  of  the  figure  (“Region”) 
describes  the  geometry  in  terms  of  the  modeling  elements  which  are  used  within  the  various  formulations 
and  codes.  Three  general  categories  are  present:  planar,  conic,  and  ellipsoid.  These  correspond 
respectively  to  the  three  common  coordinate  axes:  Cartesian,  cylindrical,  and  spherical.  Each  of  these 
can  also  have  materials  associated  with  the  modeling  elements.  The  properties  of  the  various  materials,  as 
a  function  of  frequency  or  power  level,  are  foimd  in  a  look-up  table  within  that  part  of  the  schema  labeled 
“Materials.”  In  addition  to  the  three-dimensional  objects,  there  may  also  be  defined  two-dimensional 
wires,  and  individual  points  can  also  be  used  to  model  the  object. 

An  arbitrary  number  of  coordinate  systems  can  be  defined  and  referenced.  This  allows  an  analyst  to 
decompose  geometrical  structures  into  regions,  such  as  the  fuselage,  left  and  right  wings,  or  vertical,  left, 
and  right  stabilizers  of  an  aircraft.  Each  region  would  be  referenced  to  a  local  coordinate  system,  whose 
orientation  with  respect  to  a  global  coordinate  system  has  been  defined  and  stored  in  the  database. 

Engines  can  be  modeled  separately  in  their  own  coordinate  systems  and  then  can  be  applied  to  numerous 
aircraft.  The  same  is  true  of  widely  used  communication  and  radar  anteimas.  Larger  entities  can  be 
developed  by  bringing  together  a  number  of  commonly  used,  smaller  entities.  The  local  coordinate 
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systems  are  oriented  with  respect  to  the  global  coordinate  system  within  which  all  elements  of  the  model 
reside. 

This  is  all  accomplished  within  a  database  management  system  (DBMS),  as  shown  in  Figure  7.  The 
figure  also  indicates  that  the  DBMS  is  specified  by  the  user,  requiring  only  that  it  is  SQL-compatible, 
which  is  true  for  all  commonly  used  database  management  systems.  Therefore,  a  company  can  use 
whatever  may  be  a  standard  for  that  company,  reducing  start-up  costs  and  user  training  resources.  The 
CEM  database  was  implemented  using  Microsoft  Access. 
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Figure  14.  Simplified  CEM  Data  Dictionary  Schema 


The  CEM  database  is  accessed  through  the  REF  by  software  tools  that  provide  the  means  to  take 
application-specific  CEM  data,  convert  it  into  a  data  dictionary  compliant  format,  and  either  insert  it  into 
or  extract  it  from  the  database.  Figure  15  depicts  this  process  as  it  begins  from  and  returns  to  the  REF. 
Within  the  REF  the  user  can  develop  a  computational  electromagnetics  file  for  a  specific  analysis 
requirement.  This  can  be  done  either  from  scratch  or  as  a  modification  of  an  existing  analysis  file.  A 
menu  item  on  the  Control  Panel  (Tools,  database)  is  then  accessed  to  convert  the  input  file  from  the 
GEMACS  format  into  a  data  dictionary  compliant  file.  A  utility  within  the  DBMS  manager  imports  this 
file  and  inserts  the  data  into  the  database.  Once  in  the  database  the  entire  file  or  portions  of  it  (e.g.. 
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engine  model)  is  identified  by  the  ssme  or  other  users,  and  the  process  is  reversed.  An  export  utility 
translates  the  data  into  a  data  dictionary  compliant  file.  Use  of  the  Control  Panel  database-to-GEMACS 
menu  item  results  in  a  GEMACS  input  file. 

The  significance  of  this  work  and  these  products  is  two-fold.  It  is  the  first  attempt  to  develop  a  generic 
data  model  for  the  phenomenological  computer-aided  design  and  analysis  tools  in  any  engineering 
discipline.  Presently  each  code  requires  the  input  data  to  be  in  a  somewhat  standard  sequence  and  format. 
Different  identifiers  are  used  to  refer  to  the  same  modeling  element.  Patch,  facet,  and  plate  all  refer  to  an 
area  on  the  surface.  The  description  can  be  either  a  number  of  nodes  connected  in  a  clockwise  or  counter¬ 
clockwise  direction  or  an  area  and  a  normal  to  the  surface.  These  are  all  the  same  modeling  element,  but 
one  code’s  syntax  will  not  understand  that  of  another.  This  severely  restricts  data  re-use  and  interchange 
among  analysis  tools,  even  within  the  same  engineering  discipline.  The  schema  shown  in  Figure  14  will 
among  other  things  resolve  the  differences  among  homonyms. 


Figure  15.  Data  Flow  between  REF  and  CEM  Database 


Secondly,  the  data  model  developed  for  computational  electromagnetics  can  be  used  as  a  template  for  the 
design  and  development  of  a  data  model  for  the  phenomenological  design  and  analysis  codes  used  in 
other  engineering  disciplines,  such  as  thermal  analysis  and  fluid  dynamics.  Many  of  the  modeling 
elements  are  very  similar  in  nature  and  form  as  well  as  description.  Object  descriptors  such  as  material 
constants  may  change,  and  they  may  be  dependent  on  a  parameter  other  than  frequency;  but  they  all  share 
the  characteristic  of  parametric  description. 

Developing  data  dictionaries  for  other  engineering  disciplines  while  using  that  developed  for 
computational  electromagnetics  as  a  model  or  template  has  obvious  advantages  when  one  considers  a 
global  database  for  the  product  under  development.  The  proliferation  of  names  and  data  types  will  be 
reduced.  Long-term  maintenance  and  training  will  also  be  reduced.  The  development  and  understanding 
of  DBMS  queries  will  be  simplified  as  one  crossed  engineering  domain  boundaries.  Finally,  it  will 
naturally  lead  to  an  object  oriented  database  for  phenomenological  data. 

The  existence  of  such  uniform  data  dictionaries  across  engineering  disciplines  will  also  ease  the  burden 
on  the  many  tools  and  utilities  that  would  interact  with  the  global  database.  As  an  example,  consider  the 
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knowledge-base  expert  system  preprocessor  for  computational  electromagnetics  (Section  9).  In  its  most 
basic  sense  it  takes  user  requirements  for  analysis  data  over  specified  spatial  regions,  the  structural 
description,  and  the  driving  functions,  and  it  forms  the  input  data  stream  for  the  analysis  code.  It  obtains 
the  data  it  needs  by  forming  queries.  If  the  queries  can  be  made  very  similar  in  each  of  many  engineering 
domains,  then  it  is  a  much  simpler  matter  to  compatibly  revise  all  the  queries  when  something  changes 
(e.g.,  the  database  management  system  in  use  or  the  name  of  the  dataset  being  requested). 

As  a  second  example,  consider  the  use  of  intelligent  agents  (lA)  as  proposed  in  [C.3]  and  shown  in  Figure 
16  (Figure  12  in  the  reference).  In  this  case  the  lA  monitors  the  global  database  on  behalf  of  a  specific 
user,  for  whom  and  whose  function  it  has  been  specifically  designed  and  developed.  A  SPO  officer 
would  have  different  data  needs  than  an  antenna  designer  or  system  integrator.  The  lA  would 
periodically  query  the  status  of  specific  data  and  download  updates  as  they  occur,  formatting  and 
presenting  the  data  so  that  it  is  most  useful  for  the  user.  Uniform  data  dictionaiy  entities  will  again 
facilitate  the  query  design,  development,  and  maintenance  process. 


Local  H  Local  Local  Local  Local 

DBMS  ■  DBMS  ■  DBMS  ■  DBMS  qq^s 


Figure  16.  ICE  Data  Management  Concept 


The  global  user  is  only  one  of  many  categories  of  users  who  will  ultimately  access  the  object’s  database. 
At  the  other  end  of  the  spectrum  of  users  is  the  individual  engineer/analyst  or  designer.  In  Figure  16  these 
individuals  or  members  of  a  design  team  are  grouped  according  to  engineering  discipline  (e.g.,  structural). 
Each  discipline  may  be  involved  with  only  a  specific  portion  of  the  total  object,  or  a  single  performance 
parameter  of  the  object.  The  results  of  their  individual  queries  will  be  stored  in  a  local  DBMS  over  which 
they  have  total  control  and  can  modify  without  affecting  the  “approved”  design  stored  in  the  global 
database.  The  lA  in  their  case  would  look  for  specific  types  of  data,  changes  in  the  structural  geometry, 
or  requests  for  studies  which  are  initiated  by  others  who  need  the  data  in  order  to  determine  the  effect  of 
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design  changes  in  one  discipline  on  the  object’s  performance  with  respect  to  another  engineering 
discipline. 

It  should  also  be  explicitly  pointed  out  that  the  concept  of  a  global  database  does  not  imply  that  all  the 
data  are  stored  at  one  physical  location  or  on  a  single  computer.  The  database  management  system  may 
simply  maintain  a  reference  library  which  is  used  to  seamlessly  redirect  the  user  to  the  site  at  which  the 
requested  data  actually  reside.  This  also  facilitates  configuration  control  of  die  data,  especially  with 
respect  to  identifying  and  authenticating  who  can  access  some  or  all  the  data,  and  more  importantly,  who 
can  modify  the  data.  The  data  contained  in  the  global  database  must  represent  the  current  version  of  the 
object,  whether  that  object  is  a  component  or  an  entire  system.  Proposed  designs  and  the  data  for  those 
designs  will  always  be  present,  and  ^ey  are  expected  to  be  fotmd  at  the  local  sites  and  managed  by  the 
respective  local  DBMS.  Depending  on  the  type  of  the  object,  the  degree  to  which  the  design  in  one 
engineering  discipline  affects  the  performance  in  another,  and  the  observable  parameter  set,  the  data  for 
these  proposed  designs  may  be  shared  among  a  number  of  engineers  and  analysts,  both  at  the  local  site 
and  at  sites  that  are  geographically  distributed.  If  one  or  more  of  these  proposed  designs  should  prove  to 
be  a  strong  candidate  for  acceptance,  then  they  would  be  submitted  to  the  group  having  overall 
responsibility  for  the  project.  It  is  the  members  of  this  group  who  would  be  the  only  ones  authorized  to 
decide  for  a  new  version  of  the  design  and  update  the  global  database.  This  update  would  be  made  known 
to  all  or  an  appropriate  subset  of  the  design  team  using  the  commimication  processes  and  facilities  and  the 
intelligent  agents  that  have  been  set  in  place. 

The  documents  cited  in  section  C  of  the  References  Section,  especially  C.3,  C.4,  and  C.6,  contain  more 
detailed  information  about  the  work  performed  in  this  technology  area. 
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Section  7.  Web-Based  Access 


Between  August  1995  through  September  1998  the  Ultra  Corporation,  Syracuse,  NY,  developed  a 
parallelized  version  of  the  GEMACS  (General  Electromagnetic  Model  for  the  Analysis  of  Complex 
Systems)  computational  electromagnetics  design  and  analysis  tool.  This  is  a  system-level  antenna 
performance  analysis  code  which  provides  a  sophisticated  analysis  on  a  very  detailed  model  of  a 
structure,  such  as  an  aircraft.  The  use  of  the  massively  parallel  processor  allows  for  code  execution  in 
hours  rafeer  than  days  and  weeks.  Alternatively,  it  provides  the  ability  to  test  many  more  possible 
configurations  over  a  broader  range  of  frequencies. 

In  addition  to  performing  the  parallelization  of  GEMACS  Ultra  also  developed  a  very  powerful  web- 
based  commercial  access  to  the  code  from  remote  sites.  There  are  several  reasons  for  this: 

>  Relative  ease  of  ability  to  access  the  world  wide  web 

>  Provide  accessibility  with  a  commonly  used  graphical  user  interface  (e.g.,  web  browsers) 

>  Browser  plug-ins  provide  forms  capabilities  which  allow  for  data  submission 

>  Browser  plug-ins  provide  tools  and  utilities  to  catalog,  display,  and  access  selected  records  in  the 
global  database 

>  Browser  plug-ins  provide  static  and  dynamic  visualization  capabilities  for  data  presentation  and 
viewing 

>  Browsers  and  plug-ins  have  commercial  support  and  are  available  for  a  wide  range  of  operating 
systems 

Figure  17  (part  of  Figure  4  of  [D.l])  shows  some  of  the  input  data  requirements  that  are  to  be  provided  by 
the  analyst.  This  does  not  show  all  the  functional  level  inputs  that  are  to  be  provided.  The  reader  is 
referred  to  the  full  paper  for  more  detail.  Figure  17  does  show  a  strong  correlation  with  the  concepts  of 
the  data  dictionary  and  global  database  that  are  discussed  in  section  6.  The  user  provides  the  execution 
and  geometry  input  data  for  the  computational  electromagnetics  code.  Databases  are  identified,  as  well  as 
output  data  content  and  presentation  form  and  format.  Much  of  these  data  are  identical  to  the  data  items 
named  in  the  data  dictionary  schema  shown  in  Figure  14,  and  they  can  be  directly  used  to  augment  the 
content  of  the  global  database,  if  so  approved  by  the  configuration  control  manager. 

Figure  18  shows  an  example  of  the  web  pages  that  are  used  to  develop  the  input  data  file  for  a 
computational  electromagnetics  code  execution.  A  typical  screen  will  present  command  choices  with  an 
explanation  of  each  of  the  options.  The  user  points  and  clicks  and  supplies  the  appropriate  parametric 
information  to  describe  the  problem  space  to  the  code 

Figure  19  shows  another  type  of  input  web  page  available.  In  this  example  the  GEMACS  input  file  is 
listed  andean  be  edited.  Command  can  be  inserted,  modified,  or  deleted.  This  is  useful  when  an  analyst 
is  taking  an  existing  data  input  stream  and  modifying  it  slightly  (e.g.,  change  in  frequency,  change  in  load 
conditions)  in  order  to  perform  a  study  of  a  proposed  design  as  a  function  of  one  or  more  specific 
parameters  or  ranges  of  a  parameter.  It  is  also  an  efficient  way  to  do  a  “proof-read”  of  an  input  file  before 
executing  tbe  code  to  ensure  that  the  data  are  correct.  If  one  or  more  data  items  are  not  correct,  the  edit 
capability  provides  a  chance  to  modify  the  file  on  the  fly. 
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Figure  17.  Web-Based  Access  Input  Module  Structure 


fl  Solution  Techniques  Choices  -  Microsolt  Internet  Explorer 


SotuUon  Technique  Choices 

Which  solution  technique  should  be  used  for  your  simulation? 

<?  GTED  C— 1— trie  Thaory  af  DifBractiuM  <GTD):  M  odali  eldctricalijr  large  obje  cte.  Fielde  ecaUered  by  the 

object  ace  detecnuned  by  optic  piinctples;  ray  tracing  and  reAeetion  coefficients.  The  otqeet 
geometcy  must  be  reduced  to  a  set  of  canonical  objects:  planar  plates,  c^dinders,  and  the  c^mders* 
end  c^f . 

Ci  MOM  Metfied  ef  Menwirts  (MOBI):  Models  electric  alfy  small  structures.  The  electne  field  integral 

equation  (EFIE)  and  the  magnetic  field  integral  equation ^uIFIE^  are  used  in  the  formulation.  The 
object  geometry  must  be  reduced  to  a  saries  of  wire  end  patch  segments  connected  in  away  that 
approximates  the  actual  surface. 

C  MOM/^GTD  MOM/GTD  Hjibrid!  Models  large  structures  (with  GTl^  while  elso  retaining  the  ability  to  model 

portions  of  the  structure  in  fine  detail  (with  MOM).  This  method  allows  small- to-me  drum  radiators  in 
the  vicinity  of  electrically  large  structtrres. 
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An  entire  series  of  such  input  web  pages  is  available.  Other  screens  provide  the  opportunity  to  specify  the 
work  space  and  to  identify  files  that  will  be  required  for  input  or  generated  on  output.  Mandatory  screens 
supply  authentication  data  prior  to  a  user  accessing  the  system. 


Simulation  Run  FUe  Tailoring 

The  run  file  you've  created  thus  far  and  additional  conunand  options  are  below. 
Make  any  edits  here. 
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Figure  19.  Sample  Web  Input  Page  to  Edit  Input  File 


Figures  17  through  19  have  described  the  input  processes  associated  with  the  Ultra  “Simulation  on 
Demand”  concept.  The  user  is  authenticated  into  the  system,  defines  a  workspace  and  the  files  associated 
with  that  workspace,  develops  the  input  data  which  drive  the  analysis,  and  then  initiates  the  analysis  using 
the  code  on  a  computer  and  at  a  site  specified  by  the  user.  There  is  an  analogous  series  of  figures  for 
managing  the  output  data  handling  process  available  to  the  user. 

Figure  20  shows  the  system  flow  diagram  for  the  output.  The  analyst  can  format  and  view  the  output  data 
in  a  variety  of  formats,  either  remotely  or  more  often  at  the  local  site  once  the  data  have  been 
electronically  transferred  to  the  user’s  facility.  Commercial  graphing  packages  are  available,  which  allow 
the  user  to  specify  rectangular  or  polar  plots,  include  legends,  the  plotting  of  multiple  runs  as  a  function  of 
a  parameter,  labeling,  and  color  coding. 

The  data  can  also  be  added  to  an  existing  database  at  the  local  facility  or  made  available  to  other  members 
of  the  design  team  for  use  in  other  engineering  disciplines  or  system  management.  The  data,  if  wamanted, 
can  also  be  proposed  as  a  candidate  for  inclusion  in  the  global  database,  in  which  case  a  pointer  to  its 
location  would  then  be  established  and  catalogued. 

Of  special  note  is  the  box  in  the  lower  left-hand  side  of  the  figure  which  refers  to  a  master  database  of 
pointers.  This  is  completely  in  consonance  with  the  concepts  and  proposed  implementation  of  the  global 
database  which  was  discussed  in  Section  6  of  this  report.  The  data  associated  with  the  accepted  version 
of  die  design  of  the  object  reside  where  it  makes  the  most  sense.  The  practice  of  building  up  a  complex 
model  fi-om  a  set  of  constituent  models  is  made  easier.  Consistency  within  the  hierarchy  of  numerous 
levels  of  model  complexity  (See  Figure  2.)  is  made  easier.  Tracking  and  updating  of  models  is  made 
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possible  and  manageable.  The  use  of  commercially  available  web  browsers  as  proposed  in  the  scheme 
and  implementation  developed  by  The  Ultra  Corporation  eases  the  user’s  task  of  searching  for  a  particular 
model  or  a  set  of  models  from  which  to  choose. 


Figure  20.  Web-Based  Access  Output  Module  Structure 


Figure  21  is  an  example  of  this  last  point.  The  left-hand  side  of  the  figure  shows  a  display  of  files  that 
can  be  accessed  and  archived.  These  files  could  have  resulted  from  a  study  that  had  been  performed  by 
the  user,  or  they  could  have  resulted  from  a  search  initiated  by  the  user  in  accordance  with  a  set  of  criteria 
established  by  the  user.  The  user  can  view  the  file  by  clicking  on  the  “View  File”  button.  If  it  is  of 
interest  to  the  user,  it  can  be  selected  by  checking  the  box  next  to  its  name.  The  right-hand  side  of  the 
screen  shows  the  available  databases  that  have  been  established  and  into  which  the  chosen  file(s)  can  be 
inserted.  The  user  also  has  the  opportunity  to  create  a  new  database  and  insert  the  selected  file(s)  into  it 
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Files  and  Database  Choices 
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Figure  21.  Example  Web  Search  Results 


Figure  22  shows  an  example  of  displaying  archived  files  by  graph.  In  this  option  a  thumbnail  can  be 
viewed  prior  to  fully  accessing  a  file  and  loading  it  into  an  appropriate  display  program.  Catalog 
information  is  also  available,  and  comments  can  appear  in  a  text  box.  These  comments  can  provide 
further  information  regarding  the  data  within  the  file,  such  as  identification  of  the  object  whose 
performance  is  being  quantified,  the  engineering  discipline,  the  formulation  used  for  the  analysis,  and  the 
code  used  to  perform  the  analysis.  Data  in  the  comments  field  can  also  point  to  other  files  which  may 
contain  information  relevant  to  the  performance  of  this  object. 

Figures  23  and  24  contain  examples  of  the  output  data  display  capabilities  of  the  Ultra  system.  These 
capabilities  are  provided  with  the  browser  or  within  a  plug-in  associated  with  the  browser.  The  system  is 
unusually  robust  and  provides  for  the  relatively  easy  addition  of  different  plot  types  or  the  modification  of 
existing  plot  templates.  Because  these  displays  are  Windows95/NT-compatible,  it  is  an  extremely  easy 
matter  to  insert  the  files  into  user-specified  word  processors  and  presentation  programs  for  reports  and 
presentations,  respectively.  All  the  advantages  of  user-fnendliness,  short  learning  periods,  commercial 
maintenance  and  upgrade,  and  numerous  sources  of  extensive  help  are  built  into  the  design  of  this 
package  and  its  implementation  by  The  Ultra  Corporation. 

The  documents  cited  in  section  D  of  the  References  Section  contain  more  detailed  information  about  the 
work  performed  in  this  technology  area. 

Further  information  can  be  obtained  by  contacting  Dr.  Donald  Leskiw  at  The  Ultra  Corporation.  His 
contact  information  is  P.O.  Box  50,  University  Station,  1004  E.  Adams  St,  Syracuse,  NY  13210.  The 
internet  address  is  <www.ultracorp.com>. 


Figure  22.  Example  Database  Directory  Display 


Figure  23.  Web  Browser  Display  of  Electric  Field  Magnitude 


27 


Figure  24.  Web  Browser  Display  of  Antenna  Pattern 
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Section  8.  Visualization  Package 


A  second  phase  II SBIR  was  awarded  in  support  of  the  ICE  development  program.  The  objective  of  this 
effort  was  to: 

>  Develop  a  generic  visualization  system  for  electromagnetic  simulation  computer  codes 

>  Expand  the  capability  of  this  visualization  system  to  apply  visualization  techniques  to  simulation 
codes  used  in  other  engineering  fields,  such  as  mechanical  and  environmental  engineering 

>  Develop  a  version  of  the  visualization  system  for  use  as  an  engineering  and  scientific  educational 
tool. 

At  the  time  that  this  effort  began  there  were  no  commercially  available  engineering  analysis  data 
visualization  packages  that  could  be  used  to  display  the  data  generated  by  the  phenomenological  codes. 
Most  of  the  analysis  codes  have  an  associated  native  display  capability.  Each  of  these  display  packages 
contained  some  very  specific  syntax  rules  for  the  data,  which  were  tailored  to  match  the  output  format  of 
the  analysis  code.  Hence,  data  interchange  and  re-use  were  limited.  Code  developers  and  users  could  not 
modify  the  output  format  without  requiring  a  modification  of  the  input  format  for  the  display  code. 

Trying  to  match  the  data  from  codes  in  the  same  engineering  discipline  was  very  difficult  because  data 
display  size,  labeling,  and  legends  were  not  consistent  among  the  display  codes.  This  limited  one 
valuable  technique  for  establishing  code  validity. 

It  was  also  intended  that  the  development  of  a  generic  capability  would  reduce  the  development  and 
maintenance  burden  on  phenomenological  analysis  code  developers.  Instead  of  expending  resources  on 
developing,  maintaining,  and  enhancing  a  visualization  capability  specific  to  the  analysis  code,  the  code 
developer  could  design  the  output  data  format  to  be  compatible  with  the  input  requirements  of  this  generic 
visualization  package  and  not  worry  about  generating  code  to  obtain  a  display  of  the  output  data.  More 
and  more  powerful,  user-oriented  features  would  be  available  in  the  generic  package,  compared  to  those 
features  present  in  a  locally  developed  visualization  package. 

Finally,  the  package  would  be  transportable  across  various  platforms,  from  UNIX  workstations  to  PCs  on 
an  analyst’s  desktop.  Being  commercially  supported,  updates,  enhancements,  and  revisions  would  not  be 
the  concern  of  the  analysis  code  developer  or  end  user.  Experience  with  government-developed 
computational  electromagnetics  software  has  shown  that  this  can  be  a  time-intensive,  resource-consuming 
activity. 

ARCON  Corporation  developed  a  prototype  product  called  ArconViz  consists  of  three  principal  sections: 

>  An  input  geometry  processor  to  interpret  drafting  package  files  (e.g.,  IGES,  dxf) 

>  A  graphical  user  interface  to  enter  non-geometric  input  data,  such  as  global  parameters  and 
execution  options 

>  An  output  analysis  data  processor  to  provide  visualization  of  the  computational  results  for  a 
number  of  scientific  and  engineering  simulation  programs  (specifically,  electromagnetic,  circuits, 
atomic  particle  transport,  and  thermal  analyses) 

During  the  course  of  fiiis  effort  several  high  quality  software  products  were  released.  These  products 
accomplished  many  of  the  goals  that  had  been  set  out  for  this  program,  but  on  a  single  analysis  code 
basis.  The  results  of  this  program  were  to  have  a  single  look  and  feel  across  many  design  and  analysis 
codes  and  engineering  disciplines.  This  reduces  learning  time  and  long-term  maintenance.  It  allows  for  a 
degree  of  model  interoperability  that  is  much  greater  than  that  possible  with  the  use  of  analysis  code¬ 
specific  interface  and  visualization  programs.  This  program  used  a  bottom-up  approach  in  the  design  of 
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the  interface  capability,  but  it  did  so  within  an  overarching  design  for  coherence  and  consistency 
throughout  the  individual,  bottom-up  designed  elements. 

As  an  example  of  this  correlated  bottom-up/top-down  approach  to  the  design  and  implementation 
approach  of  ARCON,  consider  the  generic  set  of  foundational  modeling  elements  which  are  used  in  the 
Arcon  Viz  geometry  modeler: 

>  Rectangular  parallelepiped  (aligned  along  coordinate  axes):  Coordinates  of  two  diagonally 
opposite  comer  points; 

>  Rectangular  parallelepiped  (arbitrary  orientation):  Coordinates  of  all  6  comer  points; 

>  Right  circular  cylinder:  Coordinates  of  base  center;  coordinates  of  top  center;  cylinder  height; 
cylinder  radius; 

>  Right  elliptic  cylinder:  Coordinates  of  top  center;  coordinates  of  bottom  center;  semi-major  axis; 
semi-minor  axis; 

>  Right  circular  cone:  Coordinates  of  base  center;  base  radius;  coordinates  of  apex;  cone  height; 

>  Truncated  right  circular  cone:  Coordinates  of  base  center;  base  radius;  coordinates  of  top  center; 
top  radius;  height; 

>  Sphere;  Coordinates  of  center;  radius; 

>  Spherical  ellipsoid:  Coordinates  of  foci;  semi-minor  axis; 

>  Wedge:  Coordinates  of  the  six  comer  points. 


It  is  to  be  noted  that  these  foundational  modeling  elements  correlate  extremely  well  with  the  foundational 
set  found  in  the  data  dictionary,  as  discussed  in  Section  6.  They  are  equally  applicable  to  many 
engineering  disciplines  and  thus  encourage  data  re-use  and  exchange. 

The  graphical  user  interface  oiArconViz  provides  a  “standard”  way  across  all  the  analysis  codes  to  add 
non-geometrical  data  to  the  input  data  stream  for  an  analysis  code.  Each  of  the  codes  selected  as  initial 
targets  for  Arcon  Viz  has  its  own  unique  format  and  syntax  for  the  execution  commands  which  govern  the 
particular  execution  of  the  code,  specifying  the  excitation,  global  parameters,  and  observable  dataset  to  be 
generated.  The  approach  to  achieve  this  uniformity  is  to  use  pull-down  menus.  A  menu  selection  will 
lead  to  a  predetermined  sequence  to  develop  the  execution  Command  stream  for  an  analysis  code’s  input. 

Figure  25  shows  the  main  graphical  user  interface  screen  for  the  Windows95/NT  version  of  the  code.  The 
UNIX  displays  are  slightly  different  (See  [E.1].),  but  they  perform  essentially  the  same  functions.  It  can 
be  seen  that  the  display  is  modeled  after  the  standard  Microsoft  Windows  format.  The  menu,  tool,  and 
status  bars  are  labeled  and  perform  functions  identical  to  those  which  most  commercially  available 
Windows  software  perform.  The  screens  for  the  various  drawing  packages  which  can  be  accessed  through 
the  Launch  menu  item  (the  interface  for  the  DesignCAD  drawing  package  is  currently  in  place),  the 
dialog  boxes  for  the  various  analysis  codes  (shown  in  the  figure  under  the  Analysis  menu  item),  and  the 
analysis  output  visualization  screens  appear  within  the  central  display  area. 

Figure  26  shows  the  first  of  many  dialog  boxes  that  the  user  encounters  after  the  GEMACS  code  has  been 
selected  fi-om  the  opening  Arcon  Viz  screen.  Through  the  use  of  the  dialog  boxes,  each  of  which  addresses 
a  particular  aspect  of  the  GEMACS  command  language,  such  as  the  location  and  type  of  external 
excitation  and  the  identification  of  the  observable  quantities,  the  problem  to  be  analyzed  is  fully  specified 
and  the  execution  can  be  initialized.  This  is  graphically  illustrated  in  Figure  27  (Figure  in.4a  of  [E.l]). 
This  figure  identifies  each  of  the  functions  that  are  available  behind  the  menu  items  of  the  GEMACS 
opening  screen  shown  in  Figure  26. 
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Figure  25.  ArconViz  Main  Screen 


Figure  27.  ArconViz  Electromagnetic  Analysis  Process 


The  Problem  Identifier  option  allows  the  user  to  name  the  project  for  future  reference  and  files  storage. 
This  option  also  allows  the  user  to  limit  the  computer  resources  expended  for  the  analysis  by  specifying  a 
limit  on  the  CPU  time. 

The  Model  Geometry  File  option  allows  the  user  to  specify  the  location  and  file  name(s)  of  single-  or 
multiple-domain  geometry  region(s).  Graphics  formats  currently  supported  include  IGES  and  dxf.  Once 
the  geometry  file  has  been  loaded,  the  user  can  process  the  geometry.  In  addition  to  viewing  the 
geometry  the  user  can  define  some  of  the  characteristics  of  the  model  which  will  be  used  in  the  analysis 
of  the  structure.  Clicking  on  an  entity  within  the  structure  will  bring  up  a  dialog  box  which  describes  the 
entity  type  and  allows  the  user  to  identify  a  material  for  that  entity.  This  in  effect  associates  an  intrinsic 
parameter  set  with  that  entity. 

The  Set  Electrical  Parameters  option  brings  up  the  screens  shown  in  Figtire  28.  The  user  is  able  to  define 
the  discrete  loads  and  distributed  impedances  associated  with  a  method  of  moments  model  of  a  structure. 
This  is  especially  useful  for  loading  an  antenna  to  represent  the  receiver,  or  to  define  an  area  that  is  not 
perfectly  conducting.  Both  of  these  modeling  options  allow  the  user  to  more  accurately  represent  the 
structure  being  analyzed  and  to  more  completely  define  the  environment  in  which  a  radiator  is  expected  to 
operate. 
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Figure  28.  Setting  Electrical  Parameters  in  ArconViz 


Select  Solution  Options  enables  the  tiser  to  define  the  structure  excitation  and  the  physics  interactions. 

The  latter  options  are: 

>  Method  of  Moments  (MoM) — a  low  frequency  solution  technique  used  for  structures  that  are  no 
more  than  a  few  wavelengths  in  size 

^  Geometrical  Theory  of  Diffraction  (GTD)  —  a  high  frequency  solution  technique  used  for 
structures  that  are  tens  of  wavelengA  and  larger  in  size 

>  MoM/GTD  Hybrid  —  a  combination  of  the  two  techniques  in  which  the  user  models  the  radiator 
and  its  near  region  with  MoM  elements  and  the  larger  structure  (e.g.,  aircraft  fuselage)  with  GTD 
elements 

>  Finite  Difference  —  a  discrete  solution  technique  for  interior  structures,  such  as  cavities  and 
waveguides 


The  analyst  also  uses  this  option  to  define  the  excitation  associated  with  the  problem,  whether  it  is  a 
source  located  on  the  structure  or  an  incident  source  in  which  the  structure  is  immersed.  Figure  29  shows 
that  an  extensive  set  of  sources  is  available  for  selection  by  the  analyst.  At  the  top-left  of  the  figure  is 
shown  the  initial  excitation  screen.  As  an  example  the  Antenna  Pattern  Source  has  been  chosen.  The 
lower-left  of  the  figure  shows  the  dialog  box  that  would  next  appear.  A  pattern  source  can  be  generated 
in  a  number  of  ways.  For  this  example  the  pattern  is  that  of  a  horn  antenna  with  a  quadratic  phase  taper. 
The  dialog  box  for  this  option  is  shown  on  the  right-hand  side  of  Figure  29.  With  this  rich  set  of 
parameters  the  analyst  is  able  to  define  almost  arbitrarily  the  excitation  for  the  problem.  Each  of  the 
other  options  available  also  provides  an  opportunity  to  very  specifically  define  one  or  more  excitations 
which  can  be  used  to  drive  the  analysis. 


Figure  29.  Setting  the  Excitation  in  ArconViz 
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Select  Computation  Options  provides  the  user  with  the  capability  to  select  regions  which  are  to  be 
connected  (e.g.,  the  fields  exterior  to  a  fuselage  coupling  through  an  aperture  in  the  skin  and  propagating 
throughout  the  interior  of  the  fuselage)  or  remain  distinct.  The  user  also  selects  the  equation  solution 
method,  whether  matrix  inversion  or  banded  matrix  iteration.  If  the  latter,  the  user  may  then  specify  the 
number  of  bands  and  a  maximum  number  of  iterations  allowed,  as  well  as  the  convergence  criterion  to  be 
used  and  percentage  for  the  process. 

These  five  options  enable  the  analyst  to  fully  describe  the  structure  model  and  specify  the  set  of  execution 
commands  to  the  GEMACS  code.  A  similar  set  of  dialog  boxes  exists  for  each  of  the  other  codes  which 
have  been  interfaced  into  the  ArconViz  system.  Because  of  the  design  of  this  computational 
environment,  other  sets  of  dialog  boxes  can  be  similarly  generated  for  other  analysis  codes.  Thus,  the 
system  is  readily  extensible. 

The  final  option  available  to  the  analyst  is  the  specification  of  the  output  and  its  display.  This  is 
controlled  by  the  Output  Options  menu  shown  in  the  left-hand  side  of  Figure  30.  Options  that  are 
available  are: 

>  Currents  on  wires  and  current  density  on  surfaces 

>  Far-field  radiation  pattern 

>  Near-field  electric  field  pattern 

>  Near-field  magnetic  field  pattern 

The  right-hand  side  of  Figure  30  shows  the  dialog  box  that  appears  when  the  analyst  chooses  the  near- 
field  radiation  pattern  option.  The  user  specifies  the  coordinate  system  in  which  the  field  is  to  be 
calculated,  as  well  as  the  beginning  and  end  coordinates  specifying  the  region  and  the  resolution  of  the 
plot  in  that  region.  The  user  also  has  the  flexibility  to  specify  whether  the  plot  is  to  be  linear  or  polar  and 
whether  one  or  both  scales  are  to  be  linear  or  logarithmic.  This  flexibility  is  available  for  all  the  output 
options. 

Finally,  ArconViz  can  produce  a  color  plot  of  the  currents  directly  on  the  structure  model.  This  is  shown 
(in  gray-scale)  in  Figure  31.  Such  a  plot  provides  “hot-spot”  information  to  the  system  designer.  This  is 
vital  information  if  there  is  an  aperture  in  the  vicinity  through  which  the  electromagnetic  field  could  enter 
the  interior  of  the  stracture  and  cause  upset  to  collocated  equipment. 

As  a  product  ArconViz  is  unfinished  at  this  time.  Work  will  continue  as  time  and  resources  become 
available.  What  is  presented  here  are  an  “artist’s  conception”  of  the  first  release  of  the  product  and  a 
description  of  some  of  what  is  currently  implemented  in  the  prototype.  It  must  also  be  kept  in  mind  that 
this  presentation  focuses  on  the  PC  version  of  ArconViz.  A  version  for  UNIX  systems  is  also  available. 
The  graphical  interface  and  presentation  are  slightly  different,  but  the  functionality  is  identical.  The 
UNIX  version  is  the  more  complete  of  the  two  versions. 

The  documents  cited  in  section  E  of  the  References  Section  contain  more  detailed  information  about  the 
work  performed  in  this  technology  area.  Further  information  may  be  obtained  directly  from  Arcon.  The 
project  engineer  was  Dr.  Bob  Joseph,  260  Bear  Hill  Road,  Waltham,  MA  02154. 
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Figure  30.  Specifying  the  Output  in  ArconViz 


Figure  31.  ArconViz  Plot  of  Current  Density  on  a  Hut 


Section  9.  Knowledge-Based  Expert  System  Pre-Processor 


If  modeling  and  simulation  is  to  be  of  any  effective  and  efficient  use  in  the  design  and  analysis  of 
modem-day  warfighter  systems,  they  must  be  founded  on  highly  accurate  computational  algorithms  and 
very  detailed  digital  models  of  the  object.  Experience  in  the  computational  electromagnetics  domain  has 
determined  that  an  aircraft  model  must  contain  on  the  order  of  500,000  to  1,000,000  elements  to 
characterize  antenna  pattern  performance,  and  backscatter  and  radar  cross  section.  Typically,  these 
modeling  elements  are  curved  triangular  facets  which  accoiint  for  the  material  properties  as  well.  Other 
engineering  disciplines  have  similar  modeling  requirements  to  levy  on  the  analyst. 

The  development,  modification  (caused  by  a  change  in  physical  design  or  frequency  in  the  case  of 
computational  electromagnetic^,  and  management  of  models  of  such  magnitude  is  an  intense  activity  in 
terms  of  time  and  analyst  attention  and  experience.  Yet,  such  highly  detailed  models  are  not  always 
required.  In  the  early  phases  of  a  design,  such  as  the  Concept  Exploration  phase  shown  in  Figure  1,  an 
aircraft  model  may  only  require  a  cylinder  for  the  model  of  the  fuselage,  or  a  detailed  model  may  only  be 
needed  in  the  vicinity  of  a  new  antenna  installation.  Figure  32  shows  two  extremes  of  computational 
electromagnetics  models.  The  number  of  variations  in  between  is  limited  only  by  the  requirements  of  the 
analysis  and  ingenuity  of  the  analyst.  How  can  one  convert  a  huge  number  of  facets  into  a  few  plates  and 
one  or  more  cylinders?  Conversely,  how  can  one  generate  a  model  with  an  area  of  high  resolution  which 
must  be  properly  coupled  to  adjacent  areas  modeled  with  a  high  degree  of  approximation?  This  requires  a 
very  careful  electrical  coupling  among  all  the  regions. 


Figure  32.  Computational  Electromagnetic  Model  Extremes 


In  response  to  these  requirements  a  contract  was  awarded  under  the  Small  Business  Innovative  Research 
(SBIR)  program  to  develop  a  knowledge-based  intelligent  preprocessor  that  will  be  used  by  an  analyst  as 
an  aid  to  develop  a  computational  model.  This  tool,  called  file  Intelligent  Computational 
Electromagnetics  Modeling  Expert  System  (ICEMES),  would  not  replace  the  analyst,  but  would  provide 
utilities  and  services  to  check  for  model  self-consistency,  assure  conformance  with  the  modeling  rules 
associated  with  the  engineering  simulation,  perform  model  viewing  and  editing,  and  develop  a  first-cut 
model  based  on  user  requirements,  observables  desired,  excitation,  and  global  parameters  (e.g., 
frequency,  resolution).  The  first  version  addresses  computational  electromagnetics  modeling  and 
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simulation.  There  will  eventually  be  a  suite  of  interactive  tools,  one  for  each  engineering  domain,  as 
shown  in  Figure  33. 

The  top  part  of  this  figure  shows  that  ICEMES  operates  within  the  Integrated  Computational 
Environment.  ICEMES  has  its  own  Graphical  User  Interface  (GUI)  which  the  analyst  uses  to  set  up  the 
problem,  generate  and  edit  the  model,  and  fire  a  prioritized  set  of  computational  electromagnetics 
modeling  rules  against  that  model.  ICEMES  reads  and  writes  to  an  internal  database  using  the  data  model 
described  in  the  data  dictionary.  Thus,  consistency  and  data  re-use  with  the  other  elements  of  the 
Integrated  Computational  Environment  will  be  maintained.  ICEMES  will  have  its  own  graphical 
geometry  and  modeling  element  editor  which  allows  the  analyst  to  import  a  representation  from  another 
CAD  package  and/or  modify  the  geometry  and  the  computational  model  for  that  geometry. 


Figure  33.  Knowledge-Base  Expert  System  Pre-Processor  Suite 


The  design  and  analysis  codes  are  expected  to  reside  on  other  machines.  This  is  shown  in  the  lower  part 
of  Figure  33.  This  is  consistent  with  the  overall  concept  of  the  Integrated  Computational  Environment,  as 
has  been  described  previously.  It  is  the  Integrated  Computational  Environment  which  provides  the  link 
between  the  network  interface  and  ICEMES. 

Figure  34  shows  the  process  which  the  analyst  will  employ.  Once  ICEMES  has  been  started,  the  analyst 
specifies  the  name  and  path  of  the  geometry  file.  This  is  followed  by  a  series  of  dialog  boxes  in  which  the 
analyst  enters  global  parameters  and  information  which  will  later  be  used  by  ICEMES  to  generate  the 
input  data  file  for  the  analysis  code.  ICEMES  will  then  use  the  geometry  and  execution  information  to 
generate  what  it  deems  to  be  an  appropriate  computational  electromagnetics  model.  The  analyst  then 
displays  the  model  in  the  ICEMES  viewer  and  can  make  modifications  to  the  proposed  model  using  a 
Smart  3-D  Graphical  Editor  or  Smart  Editor  (“smart”  because  it  is  tied  to  the  inference  engine  which  will 
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perform  validations  of  any  changes  to  the  model  in  an  iterative  manner).  These  changes  are  then 
subjected  to  validity  checks  based  on  the  rules  within  ICEMES.  Modifications  to  the  user-modified  file 
may  be  made.  This  resulting  model  is  then  viewed  by  the  user.  This  process  of  modification,  checking, 
and  viewing  is  repeated  as  often  as  necessary,  until  the  analyst  decides  that  the  model  satisfies  the 
analysis  requirements.  ICEMES  will  then  generate  the  data  file  and  exit.  The  analyst  then  executes  the 
analysis,  remotely  if  necessary,  using  the  Integrated  Computational  Environment  control  panel 
environment. 

The  Smart  Editor  that  is  being  developed  as  part  of  ICEMES  is  based  on  the  Apple  Computer  Corp. 
QuickDraw  3D  application.  Information  can  be  found  on  the  world  wide  web  at 
http://www.apple.com/quicktime/qd3d/index.html.  Figure  35  shows  the  basic  viewer  which  is  the 
foundation  of  the  visualization  package  associated  with  ICEMES.  The  basic  viewer  allows  for  rotation, 
translation,  and  zoom  of  the  object.  Data  are  stored  in  the  QD3D  metafile  format,  which  Apple  is  making 
fi'eely  available  to  developers.  According  to  the  referenced  website  QuickDraw  3D  “is  a  cross-platform 
application  program  interface  (API)  for  creating  and  rendering  real-time,  workstation-class  3D  graphics. 

It  consists  of  human  interface  guidelines  and  toolkit,  a  high-level  modeling  tool  kit,  a  shading  and 
rendering  architecture,  a  cross-platform  file  format  and  a  device  and  acceleration  manager  for  plug  and 
play  hardware  acceleration.” 


ANSWER  DflTIAL  QUERIES 
-CODE  SELECTION 
-  FREQUENCY 
-OBSERVABLES 
-ETC 


Figure  34.  ICEMES  Modeling  Process 


The  Smart  Editor  is  being  designed  to  read  data  fi-om  commercial  drawing  programs  (e.g.,  IGES,  DXF)  or 
from  computational  electromagnetics  program  input  files  (e.g.,  GEMACS).  Translators  are  being 
developed  to  convert  the  geometry  data  to  the  3D  metafile  format  native  to  QuickDraw  3D.  As  shown  in 
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Figure  36,  the  output  of  the  translation  process  is  then  displayed  within  the  Smart  Editor  visualization 
package.  In  following  the  modeling  process  shown  in  Figure  34,  the  expert  system  then  tests  the  model 
against  the  rule  set,  performs  modifications  as  necessary,  and  submits  its  version  of  die  geometry  model 
to  the  user  within  the  Smart  Editor  visualizer.  The  final  result  is  the  validated  computational 
electromagnetics  model  shown  in  the  lower  right-hand  side  of  Figure  36. 


Figure  35.  ICEMES  Visualization  Package 


A  significant  element  of  the  ICEMES  design  is  that  the  translation  of  the  CAD  drawing  or  an  existing 
CEM  model  results  in  a  “mapping”  of  the  model  data  into  an  object-oriented  metafile  environment  which 
mirrors  the  generic  KB  object  network  resident  within  the  inference  engine.  This  approach  allows  for 
firing  the  rules  directly  on  the  QuickDraw  metafile  version  of  the  models  and  executive  commands.  The 
rules  operate  upon  the  generic  I®  objects  to  produce  the  desired  modeling  results.  In  addition,  the 
translation  of  one  CEM  tool  command  set  to  another  is  accomplished  in  the  metafile  environment  and 
using  the  generic  KB  object  definitions,  rather  than  directly  performing  file  translations  (e.g.,  GEMACS 
to  NEC-BSC  input  formats,  and  so  on).  This  reduces  long-term  maintenance  and  minimizes  the  impact 
on  the  user  when  the  command  or  geometry  model  syntax  of  any  of  the  computational  electromagnetics 
analysis  tool  is  changed. 

The  heart  of  ICEMES  is  the  knowledge  base,  the  set  of  rules  which  are  used  to  develop  an  analysis  model 
(in  this  specific  case  a  computational  electromagnetics  model)  and  against  which  a  proposed  analysis 
model  is  checked  for  validity  and  self-consistency  (especially  when  the  model  is  composed  of  a 
combination  of  a  number  of  object  models).  The  rules  have  been  generated  firom  a  number  of  sources, 
most  notably  code  developers  and  documentation  and  electromagnetics  modelers,  and  they  can  be  broadly 
categorized  as  follows: 

>  Geometry  self-consistency  and  s)mtactical  checks 

>  Top-Level  rules,  generally  applicable  to  the  geometrical  description  and  computational 
electromagnetics  modeling  (i.e.,  CAD  data  are  initially  checked  for  integrity  and  completeness, 
which  is  then  followed  by  the  CEM  modeling  and  reasoning  processes) 
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>  Rules  applicable  to  a  specific  formulation  (e.g.,  Method  of  Moments) 

>  Rules  applicable  to  a  specific  code  (e.g.,  Numerical  Electromagnetics  Code) 

>  Rules  applicable  to  the  observables  desired  (e.g.,  near-field  electromagnetic  field  distribution) 

>  Rules  applicable  to  a  platform  type  (e.g.,  massively  parallel  processor).  Within  the  initial  release 
of  ICENffiS  this  section  will  be  limited,  but  it  is  considered  to  be  a  critical  area  for  future  growth. 

>  Rules  applicable  to  the  stage  of  a  product  design  (e.g.,  concept  study  phase).  Within  the  initial 
release  of  ICEMES  the  rules  are  not  segmented  to  look  at  the  level  of  modeling  fidelity  as  a 
function  of  life-cycle  stage.  This  difficult-to-define  category  can  be  automated  in  some  simple 
fashion,  but  a  considerable  amount  of  research  and  development  must  precede  the  inclusion 
within  ICEMES  of  any  powerful  and  robust  body  of  rules. 
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Figure  36.  ICEMES  Data  Translation  and  Flow 

Through  their  use  a  non-expert  can  make  minor  modifications  to  an  analysis  model  and  have  a  reasonable 
assurance  fliat  the  revised  model  is  still  valid.  This  reduces  reliance  on  and  dilution  of  the  personal 
resources  of  the  expert.  Model  performance  and  efficacy  are  increased  because  only  a  minimum 
resolution  model,  yet  very  qualified  for  the  problem  at  hand,  is  generated  and  used  in  the  execution  of  the 
analysis.  Thus,  the  time  required  for  modeling  and  simulation  is  reduced;  or  alternatively,  the  number  of 
cases  which  can  be  investigated  for  a  given  resource  pool  is  increased. 

Li  summary,  the  initial  version  of  ICEMES  is  focused  on  computational  electromagnetics.  The  design 
and  architecture  allow  for  extensibility  to  other  engineering  disciplines  which  base  their  analysis  models 
on  a  structural  geometry  (e.g.,  fluid  dynamics  to  test  the  air  worthiness  of  a  design  with  a  proposed 
antenna  location).  The  QuickDraw  3-D  metafile  will  easily  accommodate  the  material  properties  and 
parametric  relationships  associated  with  such  engineering  domains.  The  use  of  the  metafile  to  translate 
geometry  and  analysis  model  meshing  will  reduce  overhead  and  the  need  for  an  extensive  set  of 
translators.  The  correspondence  between  the  metafile  structure  and  the  data  dictionary  structure  ensures 
data  reusability  and  self-consistency  within  the  global  database  for  the  product.  Interoperability  with  the 


41 


distributed  processing  and  data  management  elements  within  the  Integrated  Computational  Environment 
(e.g.,  the  Ultra  web-based  access  system)  is  assured  through  the  use  of  the  utilities  within  the  Control 
Panel. 

The  documents  cited  in  section  F  of  the  References  Section  contain  more  detailed  information  about  the 
work  performed  in  this  technology  area.  Further  information  may  be  obtained  directly  from  Andro 
Consultants.  The  project  engineer  is  Mr.  Andrew  Drozd,  P.O.  Box  543,  Rome,  NY  13442-0543. 
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Section  10.  Summary  &  Recommendations 


When  this  project  was  in  its  early  stages,  there  was  very  little  in  the  way  of  available  distributed, 
collaborative  software  environment  technology  available.  Since  then,  hardware  and  software  advances, 
driven  by  the  commercial  market,  especially  the  world  wide  web,  have  made  this  mode  of  operation  and 
personal  interaction  commonplace.  Hence,  one  of  the  original  objectives  (proof  of  concept  and  the 
development  of  a  testbed)  has  been  accomplished,  although  not  primarily  through  the  effort  put  forth 
under  this  project. 

This  project  has  sponsored  technology  and  its  implementation  in  the  form  of  a  number  of  tools  for 
distributed,  collaborative  modeling  and  simulation  at  the  phenomenological  level.  The  most  significant 
advance  is  the  high-level  identification  of  the  requirements  for  a  global  database  for  a  product  and  the 
articulation  of  the  access,  maintenance,  and  configuration  control  issues  associated  with  such  a  database. 
Structural  data,  performance  data,  engineering  analysis  and  design  models,  as  well  as  process  data,  and  all 
information  related  to  the  design  and  manufacture,  maintenance,  etc.  will  be  resident  in  the  database  [C.3, 
C.4,C.6]. 

The  work  performed  under  this  effort  focused  on  computational  electromagnetics  as  a  way  to  validate  the 
database  concepts  [C.l,  C.2,  C.5,  C.7].  As  has  been  pointed  out,  that  can  be  extended  to  other 
engineering  disciplines  which  develop  computational  models  from  a  geometrical  description  of  the 
structure.  Work  needs  to  be  done  to  ^termine  whether  and  to  what  extent  the  models  of  one  engineering 
discipline  can  be  used  in  the  development  of  computational  models  for  other  disciplines.  Early  work  in 
this  area  has  shown  that  data  re-use  is  a  highly  subjective  and  objective  science  (art?)  and  that  a  great 
amount  of  research  and  development,  and  testing  and  validation,  are  needed  before  this  can  become 
commonplace  [A.2,  A.3]. 

A  second  area  of  significant  contribution  is  the  implementation  of  a  prototype  web-based  database  access 
and  display  package  and  simulation  on  demand  (i.e.,  remote  execution  of  a  suite  of  engineering-level 
analysis  codes)  [D.l,  D.2,  D.3].  The  current  set  of  tools  allows  an  analyst  to  display  a  thumb-nail  view  of 
the  data  and  a  textual  description  of  a  file.  The  analyst  can  then  quickly  scan  the  contents  of  a  database 
and  select  only  the  appropriate  files  for  download.  The  analyst  uses  simulation  on  demand  to  remotely 
create  project  workspaces,  transfer  input  files  for  an  analysis,  spawn  analysis  jobs,  and  download  the 
output  from  the  analysis  code.  These  capabilities  increase  efficiency  and  reduce  the  time  required  to 
prepare  data  and  execute  an  analysis.  In  this  way  the  system  analyst  or  equipment  designer  can  test  a 
larger  parameter  space  or  obtain  data  at  increased  resolutions  for  selected  regions  of  critical  parameters. 

The  third  significant  contribution  is  the  development  of  a  smart  pre-processor  to  aid  the  analyst  to 
efficiently  develop  an  appropriate  model  which  is  commensurate  with  the  requirements  of  the  analysis 
[F.4,  F.5,  F.6,  F.7,  F.9].  This  includes  both  a  Smart  Editor  which  provides  a  graphic  display  of  the  model 
and  a  rule  base  against  which  the  model  can  be  tested  for  self-consistency  and  conformity  of  the  model 
with  general  computational  electromagnetics  modeling  rules  and  with  modeling  rules  specific  first  to  a 
class  of  analysis  formulations  and  second  to  specific  codes  within  each  class.  This  will  reduce  the  time 
needed  to  develop  an  analysis  model  and  also  reduce  the  possibility  of  human  error  which  can  arise  in  the 
generation  and  handling  of  analysis  models  which  have  hundreds  of  thousands  of  elements  within  them. 

While  a  significant  amount  of  progress  has  been  made  in  achieving  the  goal  of  distributed  design  and 
analysis  and  intelligent  data  management  for  an  equipment,  subsystem,  and  system-level  product,  there  is 
much  that  remains  to  be  done.  The  simpler  task  will  be  to  take  the  existing  body  of  work  and  extend  it  to 
include  other  engineering  disciplines,  other  work  areas  associated  with  product  design  and  manufacture. 
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and  other  parameters  that  characterize  the  object  under  consideration.  This  will  be  a  continual  process 
which  logically  derives  from  the  body  of  technology  and  capability  which  exists  at  any  given  moment. 
This  is  a  matter  of  funding  and  time.  There  are  no  technology  show-stoppers  here. 

It  should  be  pointed  out  that  this  presupposes  the  existence  of  a  hardware  infrastructure  and  set  of 
protocols  which  enable  the  electronic  transfer  of  information.  Needless  to  say,  this  presupposition  is 
quickly  becoming  the  spatially  and  temporally  efficient  pervasive  reality  it  needs  to  be. 

The  more  difficult  task  will  be  to  make  its  use  the  standard  and  accepted  way  for  design  and  analysis. 
Ingrained  culture  and  the  current  way  of  doing  things  are  comfortable  and  hard  mentalities  to  convert. 
Fiscal  and  time-critical  requirements  will  go  a  long  way  toward  forcing  this  conversion.  A  volimtary 
transition,  however  gradual,  will  happen  only  when  there  is  a  demonstrable  product  to  show  potential 
users. 

A  possible  scenario  is  as  follows.  A  global  database  for  a  system  such  as  the  F-22  or  the  Global  Hawk 
must  be  developed  and  presented  to  the  SPO  and  the  various  integrating  and  contributing  contractors  who 
are  designing  equipment  changes  to  meet  evolving  operational  requirements  and  to  the  manufacturers 
who  are  implementing  those  changes.  In  the  beginning  this  will  be  an  exercise  of  catch-up  to  make  the 
database  reflect  the  current  production  block.  As  modifications  are  designed  and  implemented  the 
database  can  be  concurrently  modified  to  reflect  the  physical  hardware.  Deliverable  data  items  can  be 
added  to  the  contract  to  ensure  that  the  appropriate  data  are  delivered.  The  Air  Force  and  DoD  will  need 
to  invest  the  money  to  develop  the  initial  database. 

Concurrent  with  this  effort  is  the  need  to  increase  the  tool  set  to  facilitate  and  accomplish  the  design  and 
analysis  process.  The  computational  electromagnetics  domain  must  be  completed.  The  computational 
tools  of  other  engineering  disciplines  (e.g.,  structural,  aerodynamic,  thermal  as  a  minimum)  must  be 
incorporated  within  the  framework.  The  database  schema  for  each  of  these  engineering  disciplines, 
modeled  on  the  one  for  computational  electromagnetics,  must  be  developed  and  validated.  Smart  pre¬ 
processors  and  visual  editors  must  also  be  developed.  Perhaps  in  this  case  a  better  design  (rather  than  a 
suite  of  pre-processors)  may  be  a  core  set  of  routines  and  utilities  with  the  engineering  discipline-specific 
rule  base  incorporated  as  plug-in  modules.  This  would  encourage  consistency  among  data  items  and 
formats,  encourage  data  re-use,  and  reduce  the  long-term  maintenance  and  enhancement  requirements. 

As  mentioned  previously,  a  long-term  investment  must  be  made  to  address  the  question  of  data  and  model 
re-use  across  engineering  domains.  As  with  the  database  development  program,  the  Air  Force  and  DoD 
will  need  to  invest  the  money  to  develop  the  software,  the  documentation,  the  processes,  and  the 
technology. 

hi  both  of  these  program  areas  it  is  an  attractive  alternative  to  develop  and  pursue  a  dual-use  program 
which  is  funded  by  both  the  government  and  industry.  The  software  and  the  database  concepts  are  useful 
to  both  the  military  and  civilian  sectors.  Narrowly  focused  company-funded  programs  (e.g.,  Boeing  and 
777  airplane)  have  shown  that  what  is  proposed  in  this  body  of  work  is  both  technically  feasible  and 
economically  more  sensible.  What  needs  to  be  achieved  is  applicability  to  a  broad  range  of  products, 
robustness,  and  the  capability  to  expand  and  the  software  tools  to  enable  user  expansion. 
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OF 
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The  advancement  and  application  of  information  systems  science  and 
technology  for  aerospace  command  and  control  and  its  transition  to  air, 
space,  and  ground  systems  to  meet  customer  needs  in  the  areas  of  Global 
Awareness,  Dynamic  Planning  and  Execution,  and  Global  Information 
Exchange  is  the  focus  of  this  AFRL  organization.  The  directorate’s  areas 
of  investigation  include  a  broad  spectrum  of  information  and  fusion, 
communication,  collaborative  environment  and  modeling  and  simulation, 
defensive  information  warfare,  and  intelligent  information  systems 


technologies. 


